ในช่วงปีที่ผ่านมาหรือสองปีที่ผ่านมาได้มีการเสนอข้อเสนอให้เพิ่มข้อกำหนดในสัญญาสำหรับบิทคอยน์จำนวนมาก อย่างไรก็ตามผู้เชี่ยวชาญมักมีความเสียใจว่าอาจมีการทำสัญญาได้โดยไม่ต้องมีการเพิ่มข้อกำหนดใด ๆ หลักฐานที่เป็นหลักในเรื่องนี้มีอยู่สองรูปแบบ: รายการคำนวณที่มีอยู่ก่อนหน้านี้ที่ถือว่าเป็นไปได้ (ซึ่งจบลงด้วยโครงการ BitVM ในการนำเข้ารหัสคำสั่ง RISC-V ทุกชุด) และชุดของ "การพลิกกลาง" โดยที่ผู้พัฒนาบิทคอยน์ได้หาวิธีที่ข้อกำหนดเป็นไปได้ ถ้าไม่เป็นเพราะบางอย่างที่ปรากฏอยู่ในประวัติศาสตร์

คุณ Ethan Heilman, Avihu Levy, Victor Kobolov และฉันได้พัฒนาแผนการที่พิสูจน์ว่าความสงสัยนี้เป็นความเห็นที่ถูกต้อง แผนการของเรา Collider ทำให้สามารถมีสัญญาบนบิทคอยน์ในปัจจุบันได้ภายใต้การสมมติฐานทางคริปโตที่เหมาะสมและมีค่าใช้จ่ายประมาณ 50 ล้านดอลลาร์ต่อธุรกรรม (รวมทั้งการวิจัยและพัฒนาฮาร์ดแวร์บางส่วน)

แม้จะมีค่าใช้จ่ายที่แปลกประหลาดในการใช้ Collider การตั้งค่านั้นถูกมากและทําเช่นนั้น (ควบคู่ไปกับกลไกการใช้จ่ายทั่วไปโดยใช้ Taproot เพื่อแยกทั้งสอง) * เพียงแค่อาจบันทึกเหรียญของคุณ * ในกรณีที่คอมพิวเตอร์ควอนตัมปรากฏขึ้นจากที่ไหนเลยและระเบิดขึ้น

ไม่ต้องสงสัยว่าผู้อ่านหลายคนหลังจากอ่านเคลมเหล่านี้อาจยกคิ้วขึ้นสู่ท้องฟ้า โดยในเวลาที่คุณอ่านบทความนี้จนเสร็จ คิ้วอีกข้างหนึ่งก็จะสูงเท่าเดิม

สัญญา

บิทคอยน์ ในบทสนทนานี้สำหรับผู้ที่ไม่คุ้นเคย มีภาษาโปรแกรมที่ซึ่งเรียกว่า บิทคอยน์ ซึ่งใช้ในการอนุญาตให้ใช้จ่ายเหรียญ ในช่วงต้นของ มีชุดคำสั่งทางคณิตศาสตร์ที่หลากหลายที่สามารถใช้ในการดำเนินการคำนวณที่ไม่จำกัด แต่ในยามฤดูร้อนของปี 2010 ซาโตชิได้ปิดใช้งานคำสั่งเหล่านี้ใน คำสั่งซื้อเพื่อป้องกันข้อบกพร่องที่ร้ายแรง (การกลับไปสู่เวอร์ชันก่อนปี 2010 ของ คือเป้าหมายของโครงการฟื้นฟู อันตรายของ GOAL และ OP_CAT คือข้อเสนอที่ให้ความมุ่งหมายในทิศทางเดียวกัน ความคิดเรื่องพันธมิตร - ธุรกรรมที่ใช้ในการควบคุมปริมาณและปลายทางของเหรียญของพวกเขา - ไม่ปรากฎขึ้นเป็นเวลาหลายปี และการรับรู้ว่าชุดคำสั่งเหล่านี้เพียงพอที่จะใช้ในการดำเนินการพันธมิตรไม่สามารถเกิดขึ้นจนกระทั่งในภายหลัง โดยจุดนั้นชุมชนใหญ่โตและระมัดระวังเกินไปที่จะเพียงแค่ "เปิดใช้" คำสั่งเก่าอย่างเดียวในทิศทางเดียวกันกับที่พวกเขาถูกปิดใช้

Covenants เป็นสร้างสรรค์ที่เป็นสมมติฐานที่จะช่วยให้ผู้ใช้ควบคุมไม่เพียงเงื่อนไขในขณะที่เหรียญถูกใช้จ่าย แต่ยังควบคุมปลายทางของพวกเขาได้อีกด้วย นี่เป็นพื้นฐานสำหรับสร้างสรรค์หลายอย่างบนบิทคอยน์ เช่น ห้องเฝ้าเรือธนาคาร กระเป๋าเงินที่จำกัดอัตราการใช้จ่าย กลไกตลาดค่าธรรมเนียมใหม่เช่นพูลการชำระเงิน ไปจนถึงสร้างสรรค์ที่ไม่น่าพอใจเช่นการเงินกระจายและ MEV มีการโต้วาทีล้นเหลือจำนวนล้านคำเพื่ออธิบายความพึงพอใจของ covenants และสิ่งที่พวกเขาจะทำกับธรรมชาติของบิทคอยน์

ในบทความนี้ฉันจะหลีกเลี่ยงโต้แย้งเรื่องนี้และโต้เถียงว่า covenants นั้นเป็นไปได้กับ บิทคอยน์ อยู่แล้ว และเราสุดท้ายก็จะค้นพบ ว่า เขาเป็นไปได้ (โดยไม่ต้องใช้ค่าคอมพิวเตอร์สูงหรือสมมติฐานทางคริปโตกราฟี) และว่าโต้แย้งของเราเกี่ยวกับส่วนขยายใหม่ของ บิทคอยน์ ไม่ควรถูกจัดเตรียมไว้ว่าการเปลี่ยนแต่ละรายการเป็นเส้นคั่นระหว่างอนาคตที่ไม่มีการสัญญาหรืออนาคตที่มีการสัญญาสำหรับ บิทคอยน์

ประวัติ

เมื่อผ่านมา มีการพัฒนาประเพณีในการค้นหาวิธีที่สร้างสรรค์ในการทำสิ่งที่ไม่เป็นไปตามระเบียบ แม้กระทั้งมีข้อจำกัด การทำงานในละแวกของเครือข่าย Lightning เป็นหนึ่งในตัวอย่างเช่นนี้ ไปจนถึงความคิดที่น้อยที่รู้จักกันมากน้อยอย่างการทำการชำระเงินโอกาสสุ่มหรือการติดรางรับค่าตอบแทนสำหรับ แฮช กรณีของขอบของห้อง อย่างเช่น บั๊ก SIGHASH_SINGLE หรือการใช้การกู้คืนคีย์สาธารณะเพื่อรับ "transaction แฮช" ภายใน ตัวอ่าน ได้รับการสังเกตและสำรวจ แต่ไม่มีใครเคยพบวิธีที่ทำให้พวกเขาเป็นประโยชน์ ในระหว่างนี้ บิทคอยน์ เองได้พัฒนาขึ้นเพื่อกำหนดไว้อย่างเข้มงวดมากขึ้น ปิดประตูหลายๆ อย่าง ตัวอย่างเช่น Segwit กำจัดบั๊ก SIGHASH_SINGLE และแยกข้อมูลโปรแกรมจากข้อมูลพยานออกอย่างชัดเจน ส่วน Taproot กำจัดการกู้คืนคีย์สาธารณะที่ให้ความยืดหยุ่น ซึ่งเคยให้ความยืดหยุ่น แต่มีค่าในเสี่ยงที่จะทำลายความปลอดภัยสำหรับลายเซ็นเจอร์หรือ multisignatures

แม้จะมีการเปลี่ยนแปลงเหล่านี้ แต่การแฮ็กยังคงดําเนินต่อไปเช่นเดียวกับความเชื่อในหมู่คนตายที่อย่างใดอาจพบกรณีขอบบางอย่างที่จะช่วยให้แนวรับพันธสัญญาใน บิทคอยน์. ในช่วงต้นทศวรรษ 2020 การพัฒนาสองอย่างโดยเฉพาะทําให้เกิดคลื่น หนึ่งคือการค้นพบของฉันเองว่าพันธสัญญาตามลายเซ็นไม่ได้ตายด้วยการกู้คืนคีย์สาธารณะและโดยเฉพาะอย่างยิ่งถ้าเรามี opcode ที่พิการแม้แต่คนเดียว -- OP_CAT -- นี่ก็เพียงพอแล้วสําหรับการสร้างพันธสัญญาที่มีประสิทธิภาพพอสมควร อีกวิธีหนึ่งคือ BitVM ซึ่งเป็นวิธีใหม่ในการคํานวณขนาดใหญ่ในการทําธุรกรรมหลายรายการซึ่งเป็นแรงบันดาลใจให้เกิดการวิจัยจํานวนมากในการคํานวณพื้นฐานภายในธุรกรรมเดียว

พัฒนาการทั้งสองนี้เป็นแรงบันดาลใจให้กิจกรรมและความตื่นเต้นมากมายเกี่ยวกับพันธะ แต่พวกเขายังทำให้เราเข้าใจถึง ข้อ จำกัด พื้นฐาน ของ . โดยเฉพาะอย่างยิ่ง ดูเหมือนว่า พันธะ อาจจะเป็นไปไม่ได้ โดยไม่มีชุดคำสั่งใหม่ เนื่องจากข้อมูลธุรกรรมถูกนำเข้า ผ่านลายเซ็นต์ 64 ไบต์และกุญแจสาธารณะ 32 ไบต์เท่านั้น ในขณะที่ชุดคำสั่งที่รองรับ BitVM สามารถทำงานได้เพียงกับวัตถุ 4 ไบต์เท่านั้น การแบ่งแยกระหว่าง ส่วนน้อย และ ส่วนใหญ่ ถูกเรียกว่า "Small " และ "Big " และการค้นหา บริดจ์ ระหว่างทั้งสองนั้นกลายเป็นคำเหมือน (อย่างน้อยในจิตใจของฉัน) กับการค้นหาโครงสร้างพันธะ

การเข้ารหัสฟังก์ชันและPIPEs

ยังสังเกตเห็นได้ว่าด้วยความรู้สึกของความเชื่อมั่นที่มีน้อย คาดว่าจะเป็นไปได้ที่จะทำสัญญาเพียงอย่างเดียวในลายเซ็นต์เองโดยไม่ต้องออกจาก Big แน่นอนว่าความคิดนี้ถูกให้ออกเสียงโดย Jeremy Rubin ในบทความของเขา FE'd Up Covenants ซึ่งอธิบายถึงวิธีการใช้งานสัญญาโดยใช้ข้อกำหนดที่เรียกว่า functional การเข้ารหัส หลายเดือนหลังจากนั้น Misha Komorov ได้เสนอแผนที่เฉพาะเรียก PIPEs ซึ่งดูเหมือนจะทำให้ความคิดทางสมมติฐานนี้กลายเป็นความเป็นจริง

นี่เป็นการพัฒนาที่น่าตื่นเต้น แต่มีข้อจำกัดสองข้อหลักๆ: หนึ่งคือมันเกี่ยวข้องกับการตั้งค่าที่เชื่อถือได้ ซึ่งหมายความว่าคนที่สร้างพันธมิตรสามารถเลี่ยงกฏของมันได้ (นี่เป็นเรื่องที่ดีสำหรับสิ่งที่เหมือนที่จะเป็นตู้เก็บของ ซึ่งเจ้าของเหรียญสามารถไว้วางใจได้ว่าจะไม่เสื่อมเสียความปลอดภัยของตนเอง แต่สำหรับสิ่งที่เหมือนที่จะเป็นสระว่ายน้ำการชำระเงินที่เหรียญในพันธมิตรไม่ได้เป็นเจ้าของ) ข้อจำกัดอื่น ๆ คือมันเกี่ยวกับการเข้ารหัสปัจจุบันที่มีความชัดเจนในเรื่องความปลอดภัยไม่ชัดเจน ข้อจำกัดหลังนี้จะสลายไปด้วยการทำวิจัยเพิ่มเติม แต่การตั้งค่าที่เชื่อถือได้เป็นสิ่งที่เกี่ยวข้องกับการใช้งาน-การเข้ารหัส

ชนกัน

ภาพรวมนี้นำเรามาสู่สถานการณ์ปัจจุบัน: เราต้องการหาทางที่จะนำเอา covenants มาใช้โดยใช้รูปแบบที่มีอยู่ของ บิทคอยน์ และเราเชื่อว่าวิธีการทำนี้คือการค้นหาบริดจ์ที่เกิดขึ้นระหว่าง "Big " ของลายเซ็นต์ธุรกรรมและ "Small " ของการคำนวณอย่างสมบูรณ์ ดูเหมือนว่าไม่มี opcodes ใดที่สามารถสร้างบริดจ์นี้ได้โดยตรง (ดูส่วนผนวก A ในเอกสารของเราสำหรับการจัดประเภท opcodes ทั้งหมดตามขนาดข้อมูลขาเข้าและขาออก) บริดจ์หากมีอยู่จะเป็นการสร้างสรรค์ที่เกี่ยวข้องกับวัตถุใหญ่เดียวและแสดงให้เห็นว่ามันเท่ากับการต่อเติมของวัตถุเล็ก ๆ หลาย ๆ อัน เห็นได้จากการจัดประเภท opcodes ของเราว่านี่เป็นสิ่งที่เป็นไปไม่ได้

อย่างไรก็ตามในการเข้ารหัสลับเรามักจะประหนึ่งความคิดเช่น "เหมือนกันอย่างแท้จริง" แทนการใช้ความคิดเช่น "ความแตกต่างที่หาคำนวณไม่ออก" หรือ "ความแตกต่างทางสถิติ" และดังนั้นหลีกเลี่ยงผลลัพธ์ที่เป็นไปไม่ได้ บางที โดยใช้โครงสร้างการเข้ารหัสลับที่มีอยู่ใน Big - ฮาชและลายเซ็นเส้นโค้งทวิภาค - และโดยการสร้างสะท้อนของพวกเขาโดยใช้โครงสร้าง BitVM ใน Small เราสามารถหาวิธีที่จะ แสดง ว่าวัตถุขนาดใหญ่เป็น "ความแตกต่างที่หาคำนวณไม่ออก" จากชุดของวัตถุขนาดเล็กหลายๆ ตัวได้หรือไม่? ด้วย Collider นี้ เป็นอย่างที่เราทำในที่สุด

มันหมายความว่าอะไร? หรือจำข้อ Collision แฮช ที่เราได้กล่าวถึงก่อนหน้านี้ กฎหมายของเงินรางวัลนี้คือใครก็ตามที่สามารถ"ชน"ฟังก์ชัน แฮช โดยการให้สองอินพุตที่มีผลลัพธ์ แฮช เดียวกัน, สามารถพิสูจน์ใน Big ได้ว่าพวกเขาทำเช่นนั้น และทำเงินรางวัลนี้ได้. เนื่องจากพื้นที่อินพุตของ ฟังก์ชัน แฮช ใหญ่มาก (ทุกไบต์สตริงขนาดไม่เกิน 520 ไบต์) มากกว่าพื้นที่ผลลัพธ์ (ไบต์สตริงขนาดเท่ากับ 32 ไบต์) ด้านคณิตศาสตร์กล่าวอย่างนี้ต้องมีหลายๆ การชน. และอย่างไรก็ตาม, ยกเว้น SHA1, ไม่มีใครพบวิธีที่เร็วกว่าในการ * ค้นหา * การชนเหล่านี้นอกจากการเรียกใช้ ฟังก์ชัน แฮช อีกครั้งและเห็นว่าผลลัพธ์ตรงกับการพยายามก่อนหน้านี้

นั่นหมายความว่าโดยเฉลี่ยสำหรับฟังก์ชันแฮช 160-bit เช่น SHA1 หรือ RIPEMD160 ผู้ใช้จะต้องทำงานอย่างน้อย 2^80 หรือหนึ่งล้านล้านล้านล้านรอบเพื่อค้นหาการชนกัน (ในกรณีของ SHA1 มีทางลัดหากผู้ใช้สามารถใช้ข้อมูลนำเข้าในรูปแบบที่เฉพาะเจาะจงได้; แต่สำหรับวัตถุประสงค์ของเรา สถานการณ์นี้ถูกห้ามดังนั้นเราสามารถละเว้นการโจมตีนี้ได้) นี้ถือว่าผู้ใช้มีหน่วยความจำที่เป็นอย่างมากในการทำงาน; ด้วยสมมติฐานที่มีความเป็นไปได้มากขึ้น เราจึงต้องเพิ่มอีกหนึ่งตัวประกอบอันอย่างน้อยหนึ่งร้อยเท่านั้น

หากเราสมมติว่า SHA1 และ RIPEMD160 สามารถคำนวณได้โดยมีประสิทธิภาพเช่นเดียวกับ ASICs บิทคอยน์ที่คำนวณ SHA256 ค่าใช้จ่ายของการคำนวณดังกล่าวจะมีค่าเท่ากับ 200 บล็อกหรือประมาณ 625 BTC (46 ล้านดอลลาร์) นี่เป็นเงินมากมาย แต่มีผู้คนมีการเข้าถึงเงินดังกล่าวได้เพียงพอทำให้วิเคราะห์นี้เป็นไปได้

ในการค้นหาการชนกันที่ triple หรือสามอินพุตที่มีค่าเท่ากัน จะใช้เวลาประมาณ 2^110 งาน แม้กระทั่งด้วยการปรับสมมติฐานที่เป็นมิตรอย่างมากกับการเข้าถึงหน่วยความจำ ในการได้มา ตัวเลข นี้เราต้องเพิ่มปัจจัยอีก 16 ล้านเท่ากับค่าใช้จ่ายของเรา -- ทำให้รวมทั้งหมดถึงมากกว่า 700 ล้านล้านดอลลาร์ นี่ก็เป็นเงินมากมาย และไม่มีใครสามารถเข้าถึงในปัจจุบัน

ปมของการก่อสร้างของเรามีดังนี้: เพื่อพิสูจน์ว่าชุดของวัตถุขนาดเล็กเทียบเท่ากับวัตถุขนาดใหญ่เพียงชิ้นเดียวก่อนอื่นเราพบการชนกันของแฮชระหว่างวัตถุเป้าหมายของเรา (ซึ่งเราคิดว่าสามารถ rerandomized อย่างใดหรือมิฉะนั้นเราจะทํา "การค้นหา preimage ที่สอง" มากกว่าการค้นหาการชนกันซึ่งจะยากกว่ามาก) และ "วัตถุทดสอบความเท่าเทียมกัน" วัตถุทดสอบความเท่าเทียมกันเหล่านี้ถูกสร้างขึ้นในลักษณะที่สามารถจัดการได้ง่ายทั้งในขนาดใหญ่และขนาดเล็ก

ทางเราจึงตรวจสอบใน บิทคอยน์ ว่าวัตถุขนาดใหญ่ของเราชนกับตัวตรวจเทียมของเรา (โดยใช้วิธีเดียวกับการชนแฮช-เงินรางวัลที่ใช้วิธีเดียวกัน) และว่าวัตถุขนาดเล็กของเราชนกับตัวตรวจเทียม (โดยใช้โครงสร้างที่ฉลาดซึ่งเอาเลียบเอาไว้จากโครงการ BitVM และอธิบายอย่างละเอียดในเอกสาร) หากการตรวจสอบเหล่านี้ผ่าน แสดงว่าวัตถุขนาดเล็กและใหญ่ของเราเป็นเหมือนกัน หรือผู้ใช้พบการชนสามเท่า: วัตถุที่แตกต่างกันสองอันที่ชนกับตัวตรวจเทียมทั้งสอง จากข้อสรุปข้างต้นของเรา นั่นเป็นสิ่งที่เป็นไปไม่ได้

สรุป

การสะพานทางเล็กและใหญ่คือส่วนที่ยากที่สุดของการก่อสร้างพันธมิตรของเรา ที่จะเปลี่ยนจากบริดจ์นี้เป็นพันธมิตรจริงๆ จะมีขั้นตอนเพิ่มเติมอีกหลายขั้นตอน ซึ่งเป็นเรื่องที่ง่ายในการทำ โดยเฉพาะพันธมิตรจะขอให้ผู้ใช้ทำการลงนามในธุรกรรมโดยใช้ "กุญแจสร้าง" พิเศษ ซึ่งเราสามารถตรวจสอบได้โดยใช้โค้ดคำสั่ง OP_CHECKSIG โดยใช้บริดจ์เราแยกลายลายนี้เป็นชิ้นละ 4 ไบต์ จากนั้นเราตรวจสอบว่า nonce ของมันก็เท่ากับกุญแจสร้าง ซึ่งง่ายต่อการทำเมื่อลายเซ็นเจอร์ถูกแยกออกมา ในที่สุดเราใช้เทคนิคจากทริกของ Schnorr เพื่อสกัดข้อมูลธุรกรรมจากลายเซ็นเจอร์ ซึ่งจากนั้นสามารถจำกัดได้ในทางที่พันธมิตรต้องการ

เราสามารถทำอะไรบ้างอีกหลายอย่าง: ส่วนผนวก C อธิบายถึงการสร้างลายเซ็นแห่งแห่งหนึ่งที่อณุญาตให้เหรียญลงลายเซ็นโดยหนึ่งในเซ็ตของกุญแจสาธารณะโดยไม่เปิดเผยว่าใช้กุญแจใด ในกรณีนี้เราใช้บริดจ์ในการแยกกุญแจสาธารณะแทนลายเซ็น การทำเช่นนั้นทำให้เราได้การปรับปรุงประสิทธิภาพที่สำคัญเมื่อเทียบกับการสร้างสัญญาซึ่งเกี่ยวข้องกับ Taproot และรายละเอียดอยู่ในกระดาษ

แอพลิเคชั่นสุดท้ายที่ฉันต้องการ ดึงดูดความสนใจไปยัง ที่ถูกพูดถึงอย่างสั้นในส่วน 7.2 ของกระดาษ คือเราสามารถใช้โครงสร้างพันธมิตรของเราเพื่อดึง แฮช ของธุรกรรม ออกจากลายเซ็นเนอร์ของ Schnorr และจากนั้นเพียงแค่ทำการเซ็น แฮช โดยใช้ลามปอร์ต

ทำไมเราถึงทำเช่นนี้? ตามที่โต้ตอบในลิงก์ข้างต้น การลงลายมือชื่อลัมพอร์ทำให้ลายมือชื่อนี้เป็นลายมือชื่อที่ปลอดภัยจากควอนตัมต่อข้อมูลธุรกรรม; ถ้าการสร้างนี้เป็นวิธีเดียวที่จะลงลายชื่อสำหรับเหรียญบางอย่างพวกนี้จะได้รับความปลอดภัยจากการถูกขโมยโดยคอมพิวเตอร์ควอนตัม

แน่นอนว่าเนื่องจากการก่อสร้างของเราต้องใช้หลายสิบล้านดอลลาร์ในการใช้งานจึงไม่มีใครทำการก่อสร้างนี้เป็นวิธีการเซ็นลายเซ็นสำหรับเหรียญของพวกเขาเท่านั้น แต่ไม่มีอะไรหยุดให้ใครสักคนเพิ่มการก่อสร้างนี้ลงในเหรียญของพวกเขาเพิ่มเติมนอกเหนือจากวิธีการที่ปลอดภัยจากเทคโนโลยีควอนตัมที่มีอยู่แล้วในการใช้จ่าย

แล้วถ้าพรุ่งนี้เราตื่นขึ้นมาพบว่าคอมพิวเตอร์ควอนตัมราคาถูกที่สามารถทำลายลายเซ็นต์บิทคอยน์ บางทีเราอาจเสนอ Fork ฉุกเฉินที่ปิดใช้งานลายเซ็นต์โค้งวงกลมทั้งหมด รวมถึงการใช้จ่ายคีย์ Taproot และ OP_CHECKSIG opcode นี้ ซึ่งจะทำให้เหร็ภาพทุกคนบล็อกเหรียญของพวกเขา แต่ถ้าความเลือกที่เหลือคือว่าเหรียญของทุกคนสามารถถูกขโมยได้อย่างอิสระ บางทีมันก็ไม่มีความแตกต่าง หาก Fork ที่ปิดใช้งานลายเซ็นต์นี้อนุญาตให้ OP_CHECKSIG opcode เมื่อเรียกด้วยคีย์สร้าง (ลายเซ็นต์เหล่านี้ก็ไม่ให้ความปลอดภัยอย่างไรก็ตาม และมีประโยชน์เฉพาะเป็นบล็อกสำหรับการสร้างสรรค์ที่ซับซ้อนเช่นของพวกเรา) แล้วผู้ใช้โครงสร้างลามพอร์ตของเราก็ยังสามารถใช้จ่ายเหรียญของพวกเขาอย่างอิสระโดยไม่กลัวการยึดถือหรือการโจมตี

แน่นอนว่าพวกเขาต้องใช้เงินสิบล้านดอลลาร์เพื่อทำเช่นนั้น แต่นี่ดีกว่า "เป็นไปไม่ได้"! และเราคาดหวังและหวังว่าจะเห็นค่านี้ ปล่อย อย่างมหาศาล เมื่อคนสร้างต่อจากการวิจัยของเรา

นี่เป็นบทความของผู้เขียนแขก Andrew Poelstra ความคิดเห็นที่แสดงอยู่บนบทความนี้เป็นมรดกของเขาเองและไม่จำเป็นต้องสอดคล้องกับ BTC Inc หรือ นิตยสารบิทคอยน์